name: codex-review description: > Cross-model code review using OpenAI Codex CLI or direct API fallback. Three modes: review (diff review), challenge (adversarial break-the-code), consult (ask anything with session continuity). Catches blind spots that Claude shares with itself. Use before merging risky PRs, after large refactors, or whenever a second opinion from a different model family helps. Trigger phrases: "codex review", "second opinion", "cross-model review", "hostile review", "challenge this code", "have codex look at this".
Discover gists
| #!/usr/bin/env bash | |
| set -euo pipefail | |
| # pi Anthropic Pro/Max subscription compatibility patch | |
| # | |
| # Purpose: | |
| # Patch an installed @mariozechner/pi-coding-agent so provider=anthropic can | |
| # use Anthropic Claude Pro/Max OAuth subscription routing, similar to Claude Code. | |
| # | |
| # Why this exists: |
| RAR registration data | |
| WinRAR | |
| Unlimited Company License | |
| UID=4b914fb772c8376bf571 | |
| 6412212250f5711ad072cf351cfa39e2851192daf8a362681bbb1d | |
| cd48da1d14d995f0bbf960fce6cb5ffde62890079861be57638717 | |
| 7131ced835ed65cc743d9777f2ea71a8e32c7e593cf66794343565 | |
| b41bcf56929486b8bcdac33d50ecf773996052598f1f556defffbd | |
| 982fbe71e93df6b6346c37a3890f3c7edc65d7f5455470d13d1190 | |
| 6e6fb824bcf25f155547b5fc41901ad58c0992f570be1cf5608ba9 |
| #!/usr/bin/env bash | |
| : <<'HAPPI_DOC' | |
| <!-- happi:label=frontmatter --> | |
| # happi.md — HAPPI/1.1 | |
| > *"AI is a syscall. happi.md is the protocol."* — V>>--<<V | |
| **Version**: `happi/1.1` — current runtime. Both `happi/1.0` and `happi/1.1` envelopes are accepted; emitted events carry the runtime's version (`happi/1.1`), not the envelope's. v1.1 adds the `idr` event type, the `flags.audit=true` opt-in, and three runtime cmds (`pr.reference`, `hypothesis.register`, `quine.spawn`). | |
| **Format**: polyglot — one file, five parsers (Markdown, bash, embedded Python runtime, JSON envelope, OpenAPI YAML) |
A pattern for building personal knowledge bases using LLMs.
This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.
Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.
A pattern for building personal knowledge bases using LLMs.
This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.
Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.
| import torch | |
| import matplotlib.pyplot as plt | |
| # ── Environment diagnostics ─────────────────────────────────────────────────── | |
| # Print the runtime environment so results are reproducible and hardware-aware. | |
| print(f"PyTorch version: {torch.__version__}") | |
| print(f"CUDA available: {torch.cuda.is_available()}") | |
| print(f"MPS available: {torch.backends.mps.is_available()}") | |
| print(f"MPS built: {torch.backends.mps.is_built()}") |
This document specifies the data entities and columns that a data provider must deliver via the Plato Connector Target (PCT). Each entity corresponds to a CSV file pushed to S3.
- File Format: All files must be in CSV format with comma-separated values
- Encoding: UTF-8 encoding is required
- Header Row: The first row must contain column names exactly as specified below